Developer CD Series 1993…stman Always Clicks Twice/ADC Developer CD (1993-01) (''The Postman Always Clicks Twice'')_iso/Dev.CD 199301.iso/Development Platforms/CSMP Digests/csmp-v1-001.txt

Text File | 1992-11-18 | 56.8 KB | 1,549 lines | [TEXT/MPS ]

C.S.M.P. Digest             Thu, 27 Feb 92       Volume 1 : Issue 1

Today's Topics:

    (01) FilterTop Collaboration:  Status Report
    (02) Shutdown event
    (03) THINK C Remove Objects problem
    (04) Think C and stdin/out/err
    (05) Who has the LARGEST Mac Network?
    (06) Time Manager
    (07) Q: how do i translate code info from macsbug to resedit?
    (08) INIT
    (09) 2 QuickDraw (AAARRRGH!) questions
    (10) MPW C++ Class dereferencing of private class variables.
    (11) Drawing into windows / update events
    (12) Decompression warning
    (13) LaunchDeskAccessory
    (14) Best way to put a GUI on top of a stdio-style C program
    (15) THINK C oop and C++
    (16) How to set up a color startup screen AND color back drop screens
    (17) TIFF file format incompatible!
    (18) pascal on the mac, 1st programming course


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac directory on ftp.cs.uoregon.edu.
This is also the home of the comp.sys.mac.programmer Frequently Asked
Questions list.

These digests follow the format for the Info-Mac Digests, so you should be
able to read them with the Info-Mac Digest readers.  Let me know if that is
not true.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  Only articles that contain information are included in the
digests.  That is, if an article asking a question (and not providing any
answers) does not receive a reply, it is not included in the digests.  All
replies to each article are concatenated onto the original article in the
order in which they were received.  Article threads are not added to the
digests until the last article added to the thread is at least one month old.

Send administrative mail to [e-mail].
----------------------------------------------------------------------

(01)

From: [e-mail] (Steve Jovanovic)
Subject: FilterTop Collaboration:  Status Report
Summary: An update on the FilterTop collaboration.
Keywords: FilterTop Collaboration
Organization: UMCC

Hi Mac Netters,

This posting is to update you on the FilterTop Project,
and to invite new people to join.

What is FilterTop?

The FilterTop Team was founded several months ago with the
main goal of getting a group of Mac programmers together to
work on a Sys7-savvy product, to be distributed as Freeware
with full source upon completion.  But above and beyond that,
the goals are to meet new people and have lots of fun! :-)

Since the start, our Team has grown quite a bit.  We currently
have 50+ members, but there's always room for more!  If you are
a THINK C programmer (we also have our own Pascal Militants ;-) )
and would like to participate in our effort, we welcome you
to join.

FilterTop is a SMART file filtration/manipulation utility,
taking the best of UNIX filters and I/O redirection; Apple
Events; AI; the Mac's ease of use; (and a few surprises
thrown in).

With FilterTop, our goal is to create an app so that users
won't have to ever worry about using a barage of utilities
to (time-consumingly) get files into a format they want.
Why should we have to "manually" unbinhex and unstuff or
uncompact files when we download them to our Mac?  Just
drag the files to FilterTop's Finder icon, and it transparently
decides what to do.  (There will be a variety of config.
options).

But that's just a minor part of FilterTop's functionallity!
Wouldn't it be nice to be able to change the Type/Creator
of many files in one large batch?  How about cutting certain
fields of text in delimited text file?  How about the
eternally frustrating problem of converting text files from
UNIX or IBM to Mac, or v.v.?

There are many utilities that enable the user to do these
things now, but unfortunately, many of them are very time-
consuming for the user, and don't support batch operations.
Also, few of them are smart.  You have to make file filtration/
manipulation decisions yourself.  Worst of all, some apps
are obtrusive.  FilterTop never, never bothers the user
unless option specification is required.  But when the UI
is presented, it is transparent, non-modal, and has many
built-in smart options.  In addition, filtration and UI
interaction will be independent.  That is, file filtration
will continue going on even while you're interacting with
the UI.

The FilterTop paradigm is:  the user drops files/folders on
FilterTop's Finder icon, and it makes intelligent decisions
on what to do.  Where user-interaction is needed (very seldomly),
a transparent and convenient user-interface is presented to
allow the user to choose specific filter/s and specify
options.

There are several innovations on this idea we hope to
implement:  one is the idea of superfilters.  You take
your favorite filters and combine them into one super-filter,
so that complex actions can be performed on files.
Another innovation is being able to allow superfilters to
be assigned to a particular folder (or folders), so that whenever
FilterTop finds files in those designated folders, it
automatically goes to work.

FilterTop is being designed as an extensible architecture.
The FilterTop application is responsible for intelligence,
filter scheduling, and the user-interface.  But the filters
themselves do all the work, and we are working on an architecture
that will enable filters to be created extremely easily,
largely hiding much of the complexity of the Mac Toolbox for
the filter author.

Another major innovation in FilterTop is AppleEvents.  Other
applications will be able to call FilterTop to perform
filtration tasks on files that are sent to it!  We are even
considering the possibility of allowing menu sharing from
other applications.

How is the Team organized?

We have three development subgroups with separate mailing
lists:
    The Shell App Subgroup
    The Apple Events Subgroup
    The Filters Subgroup

Our general mailing list is:

    [e-mail].

(Please note:  [e-mail], and [e-mail]
are no longer used; we have moved over to a fast Internet system:
ais.org).

To join the FilterTop Team, please send your request or questions to:
(The FilterTop Project's Official Admin Address)

    [e-mail]

Miscellaneous:

We regret that during our last posting to the net, due to a huge
influx of e-mail and new member requests, a few people requesting
more information might not have been e-mailed back.  Now that our
mailing lists are on Internet (vs. our old system, which transferred
mail via modem and UUCP), the info. deluge will hopefully be much
easier to manage.  Sorry for any convenience.  From now on, we will
do our best to answer all queries as soon as they are received!

Status:

We are constantly coming up with new ideas, so the discussion
on our main mailing list is always active.  We have now just
begun to code, and even when the FilterTop app itself is
finished, there is limitless opportunity to write your own
filters to extend FilterTop's functionallity.  Hopefully,
we will be able to release new "filter packs" for FilterTop
every few months.  We hope that many programmers on the Net
will become involved, so that the entire Mac community can
benefit.

FilterTop might easily have been a commercial product (and
we are designing it just as if it were!), but we feel that
the whole Mac community would benefit from a a powerful
Freeware app, and hopefully our source code will make Sys7
programming a bit easier for other programmers in the future.

If you are interested in joining one of the subgroups
and/or the main mailing list, please e-mail our admin
address above.

Conclusion:

Wow--as my friend pointed out after watching me spend what
seems like hours writing this update, if you (the reader)
have made it this far through the article, you're hooked
by now :-)

We look forward to hearing from you, and hearing any general
comments/questions and suggestions that Net readers would
like to make!

Thank You,

steve jovanovic
Project Manager
FilterTop

[e-mail]

------------------------------

(02)

From: [e-mail] (Jon Pugh)
Subject: Re: Shutdown event
Organization: Apple Co.

In article <[e-mail]>, [e-mail] (David Kramer) writes:
>
> So, the question is, what event should I be looking for that signals to
> my program that Shutdown was chosen?  I assume that I will need to check
> the <multifinder aware> box in THINK C (I am using version 5), but I do
> not have a clue what the name of the event is.
>

You should either provide a Quit menu item under the File menu or support the required
Apple Events which include a Quit event.

Jon

------------------------------

(03)

From: [e-mail] (Rick Holzgrafe)
Subject: Re: THINK C Remove Objects problem
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Steve Dorner) writes:
>
> [e-mail] (Rick Holzgrafe) writes:
> >The experience made me think better of MPW, I'll tell you. The bug not only
> >trashed my project file; it (or the trashed project) kept replacing little
> >2- to 4-byte chunks of my source code with garbage. NOT a secure feeling.
>
> Stray writes to memory while you had the files open for editing?  I don't
> see why MPW would be immune to this, though perhaps it keeps less of the
> files it's editing "in memory", and so might reduce your "hit rate".

I don't see why either. I don't think it *is* immune, in fact. I suspect that
it was sheer dumb luck that my bug was hitting... well, whatever it hit to
cause all that damage in Think C, and that it could just as easily have
happened in MPW. But at least MPW doesn't put so many of its eggs in the one
basket of the project file. It may be a little more resistant than Think C,
for that reason.

> --
> Steve Dorner, U of Illinois Computing Services Office
> Internet: [e-mail]  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
>                 "What is Truth?"--Pontius Pilate.

- ---------------------------------------------------
Rick Holzgrafe   [e-mail]   AppleLink HOLZGRAFE1
     {sun,voder,nsc,mtxinu,dual}!apple!rmh
Apple Computer, Inc.
20525 Mariani Ave. MS: 3-PK
Cupertino, CA 95014
     --- My opinions, not Apple's.

------------------------------

(04)

From: [e-mail] (Russell Street)
Subject: Re: Think C and stdin/out/err
Organization: University of Auckland, New Zealand.

[e-mail] (J R Hughson) writes:

>    I am trying to port unix filters over to the mac.  We have a front
>end working, but the filters have yet to work.  What I need to be able to
>do is set stdin, stdout, stderr to filenames which are passed in.  I know
>that ccomand does such things and I have puzzeled over the source for
>this among other things.  The tools (filters) can't be modified from portable
>c.  They need to be compiled as code resources.  Which source files
>will I need to include since ansi-a4 lacks file routines?

Standard C lets you reopen any stream with another file name.
So for instance you could redirect stdout with

    freopen("new-in.dat", "wb", stdout);

freopen returns NULL on failure or the stream on success.

[Good idea to include the "b" if you are using binary data.
You will get LF to CR translation otherwise]

This standard C call is documented in the Think C ANSI libraries
manual.

In fact, looking at the man page for freopen on this UNIX machine
I see:

} freopen is typically used to attach preopened streams associated
} with stdin, stdout and stderr to other files.

As for stdio in code resources.  The complete ANSI sources come
with Think C.  It is not that difficult to modify them to
include the FILE stuff and be included in a code resource.

I would suggest making a copy of the sources and taking out
all the stuff you don't want, such as the console libraries,
signals, assertions.  Presumably the UNIX sources have global
variables or statics so a few more global variables are not
going to hurt.

Hope this helps...
- -----------------------------------------------------------
Russell Street ([e-mail])
    "But that's your pigeon, Major"
    "So it is. How did that get out! Abdul - take this pigeon
    away and bring me a clothes brush!"
        The Goon Show "The Telephone"

------------------------------

(05)

From: [e-mail] (greg ferguson)
Subject: Re: Who has the LARGEST Mac Network?
Organization: Motorola, Inc.

In article <[e-mail]>, [e-mail] (Glenn Stauffer) writes:
>
> In article <[e-mail]>, [e-mail] (Andrew E Page) writes:
> >
> >     Who has the largest Macintosh Network?
> >
> >
> >     How many zones do they have, do they support some WAN as well
> >     as a LAN protocol?
> >
> >     What is their preferred hardware?
> >
> >     Just curious.
> >
>
> In an article on the NetOctupus LAN management software in Info World, they
> state that Motorola's Semiconductor Products Sector in Phoenix recently
> licensed the product for 15,000 Macs.
>
My, how that gets around. I'm the one who set up the order. I think
that the 15,000 will cover our sector's growth for a couple of years,
including the international sites. I don't think we're there yet.

Greg Ferguson [e-mail]


+++

From: [e-mail] (Brian Bulkowski)
Organization: Novell Inc.

I heard of University of Texas at Austin boasting of having a real
large network, they claimed 12,000 AppleTalk devices. National will
probably outdistance them shortly. I don't know much about UTA's
topology. Probably mostly ethernet + localtalk and very little WAN.

Here at Novell we're pretty small: less than 1000 macs, but we do a bit
of WAN over T1. Usta do IP tunnels, went to native AppleTalk. About
60 zones.

BrianB
[e-mail]

+++

From: [e-mail] (Allen Kitchen)
Organization: The University of Texas at Austin

    I have been told that the University of Texas has the largest single
site quantity of Macs in the world. Supposedly 50,000 on campus, and most of
them part of the network.
    So why can't I find a decent software store in this town? :)

allen
[e-mail]

------------------------------

(06)

From: [e-mail] (Rex Cammack)
Subject: Time Manager
Organization: USC  Department of Computer Science

  My department just got THink Pascal Last week and I have not work with pascal
in the last say 5-8 year.  My advisor readed that I might get millisecond
accuracy by using the Time Manager.  However he want to use the actual time in
milleseconds.  I investagated this an saw that millisecond are used in this
quene but How would one capture the numerical millesecond value.  My advisor
needs a millesecond timer.  Has any one work with the time manager in this way
If so could you provide me with any and all useful information
Thank to all
Rex
--
==============================================================================
Rex Cammack                 University of South Carolina
[e-mail]       Humanities and Social Sciences Laboratory
(803)-777-7840                        Columbia, S.C. 29208

+++

From: [e-mail]
Organization: BC Systems Corporation

In article <rex.695942617@andy>, [e-mail] (Rex Cammack) writes:
>
>   My department just got THink Pascal Last week and I have not work with pascal
> in the last say 5-8 year.  My advisor readed that I might get millisecond
> accuracy by using the Time Manager.  However he want to use the actual time in
> milleseconds.  I investagated this an saw that millisecond are used in this
> quene but How would one capture the numerical millesecond value.  My advisor
> needs a millesecond timer.  Has any one work with the time manager in this way
> If so could you provide me with any and all useful information
> Thank to all
> Rex
> --

I have once before in testing the Time Manager to do calanders etc.  I don't
have the code here in front of me though.  I can tell you that I got my
information from Macintosh Revealed Vol. 1 & 2.  These books describe how to
use the date and time functions.  It's based on a RandSeed if I remember
correctly.  You can convert from date and time to a longINT and back again very
accurately.


--

[e-mail]
British Columbia, Canada

------------------------------

(07)

From: [e-mail] (Thomas R. Kimpton)
Subject: Re: Q: how do i translate code info from macsbug to resedit?
Organization: Digital Technology, International

In article <[e-mail]> [e-mail] (Andre "Just A Plumber" Srinivasan) writes:
>
>when i'm looking at a function that doesn't have a symbolic name,
>macsbug tells me that i'm in 'CODE 001 D98' + CC.  how do i translate
>this so that i can find the function in resedit using the code
>resource disassembler?
>
>thanks.
CODE    resource type of code resource (many types possible!
    e.g. WDEF, CDEF, MDEF, LDEF, MBDF, scod, etc.)
0001    short hex number giving resource ID of code resource
0D98    short hex number giving file reference number of open file
00CC    short hex number giving offset into resource

Open the program with ResEdit, open the appropriate CODE(code)
resource (remembering that the numbers are in DECIMAL in
ResEdit), look in the second column (address, not first
column (offset)) for 00CC, voila.

Using the 'file' dcmd you can use the file reference number
to find out which file code is being executed from.

Tom.

--
- -
Tom Kimpton                            UUCP: uunet!dtint!tom
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

------------------------------

(08)

From: [e-mail] (REDMAND CHRISTOPHER M)
Subject: Re: INIT
Organization: University of Colorado, Boulder

[e-mail] (Peter Sutton) writes:

>I am about to attempt to write an INIT so
>are there any examples of INITs source code freely available somewhere?
>I have some experience of Mac programming but have not written one
>of these beasts - any pointers. Do I have to use assembler?
>The development environment that I have most ready access to is MPW and
>I would like to do the development under MPW C as much as possible.
>In addition are there any, and if so which, technical notes might
>be of use.

'Tis not necessary to use assembly language, but for the first time writing an
INIT, I _HIGHLY_ recommend it.  Debugging can be an amazing chore unless you
are a C master who can readily recognize and map the assembly code instructions
to the C source lines.

The best solution I've come across is to put together an assembly language
platform for INIT development, that simply allocates the necessary space (if
any) for your ram-resident routines and globals, and calls an install()
routine.  Once this basic platform is bullet-proof, any further development you
do can be written in any language, and tested outside of the INIT under a
language-specific debugger.

I too am in the throes of developing my first REAL init.  If you're interested
in my code, reply via e-mail:  [e-mail]

    - Chris

*******************************************************************************
Disclaimer:  I'm not speaking for ANYONE that doesn't even spell my name
             correctly.
*******************************************************************************

------------------------------

(09)

From: [e-mail]
Subject: 2 QuickDraw (AAARRRGH!) questions
Organization: BC Systems Corporation

I have a couple of QuickDraw questions.  I'm trying to write a customized
graphing program that will do only pie charts (I only need pie charts for
this).
Question 1:    my source code reads in a text file with 4 numbers in it
(currently), converts these numbers to a percentage (for easy graphing in a Pie
chart) and then converts that percentage to degrees.  This works like a hot
darn if the four numbers read in total 100 in the sum but if they are more or
less (at least in some cases) the pie chart doesn't graph properly.  I get some
white space in the last pie slice.  I'm using THINK Pascal 4.0 with System 7 on
a Mac Plus with 4 MEGs of RAM.  I'm using the PaintArc procedure.  The main
problem is that this and other XXXXArc procedures take integers as arguments so
when doing the conversion from a percentage to the integer I do the following:
        ArcLength := Ord(Round(num*100))
this takes the Real num*100, converts it to a LongInt and then the ORD function
converts it to the integer I need for the function.

    It would be a lot nicer if these QuickDraw routines could take
reals!!!!!!!!!

Question 2:    I would like the end result to be a PICT style pie chart that
can be resized by the user (MacDraw like) but I can't find for the life of me
how to do this.  MacDraw has PICT style drawing, Symantec's own GreatWorks has
it, other programs have it, why can't I do it?????!!

Any help is muchly appreciated.

Carl B. Constantine

+++

From: [e-mail] (Chuck Shotton)
Organization: OAC, U of Texas Health Science Center

In article <[e-mail]>, [e-mail] writes:
>
[Passing on question 1]

>
> Question 2:    I would like the end result to be a PICT style pie chart that
> can be resized by the user (MacDraw like) but I can't find for the life of me
> how to do this.  MacDraw has PICT style drawing, Symantec's own GreatWorks has
> it, other programs have it, why can't I do it?????!!
>

Call OpenPicture before you begin drawing your pie chart and ClosePicture after
you're done. Now you have a handle to a picture that can be drawn in any size
destination rectangle you want (DrawPicture). Stretching and dragging is left
as an exercise to the reader. :)

Chuck Shotton

------------------------------

(10)

From: [e-mail] (Dave Morgan)
Subject: MPW C++ Class dereferencing of private class variables.
Organization: Evans & Sutherland Computer Corporation

     I recently purchased MPW C++, and in their example programs, they
are very careful about telling you to watch out for dereferences.  They
have a temporary variable in each method and will pass the temp's address
instead of the address of the class private variable.  For instance, suppose
class Window has a private variable fwindow..

Window::DoMouse(...)
{
  WindowPtr wtmp;

  FindWindow(..., &wtmp) // Instead of using &fwindow.
  fwindow = wtmp;
}

     Can someone clue me in on the evils of dereferencing a private variable??

-Dave

Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Re: X11R5 and Motif1.1.1
Keywords: X motif
Distribution: na
References: <[e-mail]>

[e-mail] (Lee Glenn) writes:

>Well, here's my problem:

>I've compiled X11R5 for our Sun system with the MotifBC flag set to YES.
>We've been running X11R4 with Motif1.1.1 just fine.  After compiling one
>of our motif applications, we now dump core when trying to use a scrollbar
>widget.

>Thinking that I may need to re-compile the motif libraries with the R5
>includes, I find that some includes no longer exist in R5.  (Xlibos.h)

>Has anyone else had any of these problems?  Anyone have any suggestions?

>Thanks.


>--
>Lee Glenn                    I own an Amiga, but it's not my religion.
>Senior Software Engineer
>Microware Systems Corp.
>(UUCP: uunet!mcrware!leeg) (Internet: [e-mail])

     I had to change a couple of things to get Motif to compile after
installing X11R5 on our Suns.  They were:

     1) Add the line:

            #include <fcntl.h>

    to the file <Motif>/lib/Mrm/MrmIfile.c somewhere by the other
    includes.

     2) Comment out the line:

            #include <X11/Xlibos.h>

    in <Motif>/lib/Xm/Vendor.c

     Hope this helps...
--
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
David Morgan                                            "Can we go home, yet??"
System Programmer                                    [e-mail]
Evans & Sutherland                          ...uunet!javelin.sim.es.com!dmorgan

+++

From: [e-mail] (Joe Francis)
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (Dave Morgan) writes:

> They
> have a temporary variable in each method and will pass the temp's address
> instead of the address of the class private variable.

I believe the phenomenon you see in the sample code has nothing to do
with the access specifier of the data member, but rather with the type
of the class.  Classes derived from HandleObject have their data
members sitting in a macintosh handle, which can move around in memory.
  Passing addresses to these data members to any routine that can move
memory can result in the data member moving "out from under" the
address before the called routine writes the value.  Note that most mac
ToolBox calls can move memory, and that even calls to your own routines
that seem not to move memory can move memory if they are in a different
segment and that segment is unloaded.  Even if you know that 1) your
routine doesn't move memory, and 2) that it is in a loaded segment, if
your code depends on this it will break when you modify that procedure
later  on in such a way as to vilate either 1 or 2.

Again, you only need to worry about this for data members of classes
which are handle based.

------------------------------

(11)

From: [e-mail] (Steve Christensen)
Subject: Re: Drawing into windows / update events
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Steve Howell) writes:
>In IM I-278 it states that "In most cases,
>it's best *never* to draw immediately into a window; when you need to
>draw something, just keep track of it and add the area where it
>should be drawn to the window's update region." It also says "the application
>has to keep track of the window's contents, usually in a data structure."

>Well, my questions:

>  * what sort of data structure have people found useful? (If, for example,
>    the window contains icons, pict's, check boxes and the like).

Arrays, linked lists, etc.  It depends on what you're application does and
what has to be drawn.  Obviously if you only have a few items in a window,
you could just draw each in turn.

>  * what problems arise when one draws directly into a window?

Typically the window will be re-drawn twice: once when you draw everything,
and once when you process an update event.  If everything is handled when
your application receives an update event, the window will automatically be
kept up-to-date.

>  * how do you handle an update event? by traversing the data structure and
>    redrawing the entire contents of the window?

If you don't have too many items to draw, you can simply draw everything
since only the area to be updated will actually be redrawn.  If you have
a potentially large number of items to draw (for example, cells in a
spreadsheet), it makes more sense to draw only those items whose bounds
intersect the update region.

steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.

------------------------------

(12)

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject: Re: Decompression warning
Organization: University of Waikato, Hamilton, New Zealand

Here's another point that bit me, only it's not a bug, it's a feature.

The QuickTime documentation warns you that, when passing the address
of the data buffer to the compress/decompress calls, it *must* be a
32-bit clean address. That is, if it's a dereferenced handle, you must
call StripAddress on it. I was forgetting to do this in one of my programs,
and then I was wondering why it would work perfectly on my LC at home,
but crash every time on the IIfx at work.

Then I remembered that my LC (which has 10MB of RAM) runs in 32-bit mode
most of the time, while the 8MB IIfx runs in--you guessed it--24-bit mode.
Simple when you think about it...

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Godliness doesn't mean that you be so heavenly minded that you're no
earthly use.                                           -- W G P

------------------------------

(13)

From: [e-mail] (Thomas R. Kimpton)
Subject: Re: LaunchDeskAccessory
Organization: Digital Technology, International

In article <[e-mail]> [e-mail] (Thomas R. Kimpton) writes:
>
[deleted]
>Also I didn't indicate that the event queue was empty,
>no pending events.
>

Another oops, MacsBug's Evtq dcmd was lying to me.  I got
paranoid and put checks in the code for events, and 'lo and
behold there were pending update events for the window
behind the SFPGetFile.  I took care of them, and the
Chooser came right up.  Luckily I had read TechNote
"#304: Pending Update Perils" several days before and
this must have been in the back of my mind to make
me check.  Thanks to those who emailed me suggestions.

Anyone have a reliable Evtq dcmd?

Tom.

--
- -
Tom Kimpton                            UUCP: uunet!dtint!tom
Digital Technology Int.                [phone]
500 W. 1200 South, Orem UT, 84057      FAX [phone]

+++

From: [e-mail] (Matthias Ulrich Neeracher)
Subject: Re: LaunchDeskAccessory
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Thomas R. Kimpton) writes:
>In article <[e-mail]> [e-mail] (Thomas R. Kimpton) writes:
>>
>[deleted]
>>Also I didn't indicate that the event queue was empty,
>>no pending events.
>>
>
>Another oops, MacsBug's Evtq dcmd was lying to me.  I got
>paranoid and put checks in the code for events, and 'lo and
>behold there were pending update events for the window
>behind the SFPGetFile.

Your evtq dcmd wasn't lying to you. Update events are not put into the event
queue, but generated by GetNextEvent().

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_

------------------------------

(14)

From: [e-mail] (FUKUMOTO Atsushi)
Subject: Re: Best way to put a GUI on top of a stdio-style C program
Organization: Anzai Lab., Keio Univ., Yokohama, Japan.

I happen to have been doing the port of GhostScript for Macintosh
(though it is suspended these days because I'm quite busy for other
things).


In article <[e-mail]>,
    [e-mail] (Tony Gedge) writes:
> I've been working on a port of GhostScript to the Macintosh and have got
> it in a semi-working state (i.e. parser is going, some problems with
> halftoning)


So perhaps my port might be better than yours.  If you are interested,
let me know, I'll send you.  It might help you.  (Though my code is
ugly.)

I'm using TCL for user interface.  I modified console I/O library so
that it is a subclass of CEditText, yet it is still usable from
standard C I/O library as stdin/stdout/stderr.

I'm planning to include the composite-font support for Japanese text
handling.  Only if I could find time to do it.


In article <[e-mail]>,
    [e-mail] (Jon W{tte) writes:
> This is somewhat of a black art... In order not to lose too
> much overhead; you should have a wrapper function that checked
> the status of TickCount, and if more than 1 tick has passed, idle
> with a sleep time of ~5 ticks.


I inserted such a code into the interpreter main loop.


>
> Remember that Ticks is a lo-mem global that's NOT available under
> A/UX.


Interesting thing was that replacing TickCount() with Ticks didn't
have much effect to execution speed.  Perhaps 1% or so, though I've
not done extensive benchmarking.


                        FUKUMOTO Atsushi
                        [e-mail]

+++

From: [e-mail] (Larry Rosenstein)
Organization: Object Based Systems, Apple Computer, Inc.

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>.oz.au> [e-mail] (Tony Gedge) writes:
>
>   the menus and so on.  The only way I can think of is to profile the
>   execution of it and insert hooks to do the menu/window handling in
>   the tight loops.
>
>Not in the tightest loops, I hope... That woudl give awful performance.
>
>much overhead; you should have a wrapper function that checked
>the status of TickCount, and if more than 1 tick has passed, idle
>with a sleep time of ~5 ticks. You should also have a flag that

When I ported the pbmplus image processing tools to MPW, this is the basic
approach I took.  I also used the -trace on feature of MPW C to have the
wrapper called at each routine entry/exit.  This gave reasonable background
performance in most cases.  (For better performance, I wrote a script that
inserted a call to my wrapper in each loop.)

I think you can wait as much as 4-5 ticks between each call to WaitNextEvent
and still provide good background performance.  I'm not sure that I would
use a non-zero sleep value.  The sleep value is intended for telling the
system that you don't need any CPU time at all; if you're doing something,
there's no reason to sleep.

The hardest part will be handling the events that come in.  (This is easy in
an MPW Tool because the Shell does it for you.)


--
Larry Rosenstein, Apple Computer, Inc.

[e-mail]
(or AppleLink: Rosenstein1)

------------------------------

(15)

From: [e-mail] (SKELTON,JOEL PHILLIP)
Subject: THINK C oop and C++
Organization: Georgia Institute of Technology

I couldn't find any comparision in recent news but I'm certain
this must have been discussed before. I just inherited a mac
with THINK C on it and after glancing through the manuals it
seems that THINK C supports C++ like stuff. I couldn't find
any mention of C++ in the manuals I'd received with the mac.

How close is THINK C to C++? I could see that there were some
differences but can these be overcome to get an existing C++
program that makes extensive use of inheritance and op. overloading
to work without completely mangling the original code?

Or did I just miss the paragraph in the manual that said that
this is just a teaser to get you the buy their C++ compiler (if
there is one?)

jps
bf


--
Joel Skelton   --    North Avenue Trade School, Dept. of Round Things
[e-mail]   (ask for Scooter Technologies, and receive)

+++

From: [e-mail] (Eric W. Sink)
Organization: University of Illinois at Urbana-Champaign

In <[e-mail]> [e-mail] (SKELTON,JOEL PHILLIP) writes:

>How close is THINK C to C++? I could see that there were some
>differences but can these be overcome to get an existing C++
>program that makes extensive use of inheritance and op. overloading
>to work without completely mangling the original code?

Think C is closer to C than C++.  Its features are patterned after
C++, but C++ has much that Think C lacks (perhaps to its benefit).

You will not get an existing C++ program which makes extensive use of
operator overloading to work without completely mangling the
original code.

>Or did I just miss the paragraph in the manual that said that
>this is just a teaser to get you the buy their C++ compiler (if
>there is one?)

Nope.  There isn't one.  Wish there were...

--
Eric W. Sink,  Spatial Analysis and Systems Team
USACERL, P.O. Box 9005, Champaign, IL 61826-9005
1-800-USA-CERL x449,   [e-mail]

+++

From: [e-mail] (Steve Krans)
Organization: People-Net [pnet51], Minneapolis, MN.

I don't understand why Symantec is lagging so far behind in releasing a C++
compiler.  Are there efforts going swaying towards the pc side of the market,
or what?  Are there any other companies that sell C++ compilers?  There's MPW
C++, right?  Steve.

UUCP: {tcnet, crash, quest}!orbit!pnet51!skrans
ARPA: crash!orbit!pnet51![e-mail]
INET: [e-mail]

+++

From: [e-mail] (Matthias Ulrich Neeracher)
Subject: Re: THINK C oop and C++
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Steve Krans) writes:
>I don't understand why Symantec is lagging so far behind in releasing a C++
>compiler.  Are there efforts going swaying towards the pc side of the market,
>or what?  Are there any other companies that sell C++ compilers?  There's MPW
>C++, right?  Steve.

As far as I know, Symantec bought Zortech, which has a C++ compiler for the
Mac. Other companies ? I don't know. If you want a really interesting
experiment, offer Cygnus $200'000 for porting g++ to the Mac :-)

Matthias

- ---
Matthias Neeracher                                   [e-mail]
  "... Rice walked out wondering if the world was nothing but wimps,
   pimps, psychos and sex fiends" -- James Ellroy, _Suicide Hill_

------------------------------

(16)

From: [e-mail] (David Dantowitz)
Subject: How to set up a color startup screen AND color back drop screens
Organization: UCLA Computer Science Department

How does one set up a color startup screen.  I have a color PICT in
a file, but it's beeing shown in B&W.  Do I have to write an init to
start up a copy of quick draw and draw it myself?

Also, how does one hook into the desktop to provide a new back drop picture?

Thanks.
--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...

+++

From: [e-mail] (David Dantowitz)
Subject: Re: How to set up a color startup screen AND color back drop screens
Organization: UCLA Computer Science Department

Okay, I answered the first part myself:

I cleared the PRAM of my ci last week, and at boot time it didn't know it had
color.  After boot-up it was in color mode, though and that's what confused
me.  A quick trip to the monitor control panel fixed this.

--
David Dantowitz
[e-mail]

Singing Barbershop when I'm not computing...

+++

From: [e-mail] (Steve Howell)
Organization: University of Tasmania, Australia.

[e-mail] (David Dantowitz) writes:


>Also, how does one hook into the desktop to provide a new back drop picture?

Try using "DeskView" - it lets you have a colour backdrop. Works best if your
monitor is set in "millions" mode, 'cos then you don't get palette hassles.
Unfortunately, this program only let's you have one backdrop... you can't
get it to randomly choose one from a collection.

    ps
You can download DeskView via anonymous FTP from sumex-aim.stanford.edu
or one of it's shadows, I think it is in the info-mac/ex directory.

------------------------------

(17)

From: [e-mail] (Jerry Sy)
Subject: TIFF file format incompatible!
Organization: Case Western Reserve University, Cleveland, OH (USA)

I have files in PhotoShop that I saved as TIFF format (it doesn't matter
whether Mac or PC format), but when I try to read it in OMNIPAGE,
it does not recognize the TIFF format, and TIFF is the only format
OMNIPAGE can read.

any ideas ?

jerry

+++

From: [e-mail]
Subject: Re: TIFF file format incompatible!
Organization: University of Geneva, Switzerland

> I have files in PhotoShop that I saved as TIFF format (it doesn't matter
> whether Mac or PC format), but when I try to read it in OMNIPAGE,
> it does not recognize the TIFF format, and TIFF is the only format
> OMNIPAGE can read.
>
> any ideas ?
>
> jerry

You can try to save it as a non-compressed TIFF file. I often encounter this
kind of problem with TIFF format.

Hope it will work.
Sincerely,
Steve Jordi
Dpt of Geophysics
University of Geneva
Switzerland
[e-mail]

------------------------------

(18)

From: [e-mail] (Claude Lapointe)
Subject: pascal on the mac, 1st programming course
Organization: Ballistic Research Lab (BRL), APG, MD.

My daughter (college freshman) is taking her 1st programming
course, pascal.

borland's pascal is provided by the school for both their
ibm lab and mac lab.

The instructor uses a mac (as does my daughter, who will shortly
get her very own IIci 5/80 w cache), dislikes borland's pascal,
and recommends THINK pascal (states it is much more powerful
and complex than is needed but has documentation) and MacPascal
(which he uses himself, but which has no documentation).

I need some advice in a hurry.

THINK pascal is expensive ($160-170 mail order), and I'm willing
to believe the prof's assessment thereof - but a BIG plus is
documentation and fast availability.

MacPascal is of unknown price, a mere interpreter, has no
documentation, and is of unknown availability.

THINK pascal would probably be of continuing utility. Perhaps its
reputed complexity could be overcome by initially using only
its interpreter (presuming it has one and so doing is possible).
Documentation seems to me to be of great value.

MacPascal has the great advantage of being used by the guy
who teaches the course - but it has no documentation(?), and I
don't know how to get it.

Corrections of my errors, recommendations, and source info please.

+++

From: [e-mail] (Chuck McMath)
Organization: MSD

In article <[e-mail]>, [e-mail] (Claude Lapointe) writes:
>
>
> My daughter (college freshman) is taking her 1st programming
> course, pascal.
>
> borland's pascal is provided by the school for both their
> ibm lab and mac lab.
>
> The instructor uses a mac (as does my daughter, who will shortly
> get her very own IIci 5/80 w cache), dislikes borland's pascal,
> and recommends THINK pascal (states it is much more powerful
> and complex than is needed but has documentation) and MacPascal
> (which he uses himself, but which has no documentation).
>
> I need some advice in a hurry.
>
>    .....
>

There are really two alternatives: Think Pascal is certainly one, and for
your daughter it _may_ be overkill.  It is an excellent product, and has
been around a while.  You can do just about whatever you want to with it,
and the debugging facilities are nice.

MacPascal does not exist any longer (I believe).  Symantec (publishers of
Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
seen it, but I believe that it's an updated MacPascal - an interpreter, not
a compiler.  I owned MacPascal when it existed, and frequently got into
situations where it did not suffice for my purposes.  However, I was trying
to do all sorts of crazy Mac-like things, not take a course in programming.

I am not sure of the price difference between Think Pascal and Just Enough
Pascal, but if either you or your daughter have ANY interest in programming
the Mac for fun or profit, spring for Think Pascal (after all of the tuition
you're paying, what's another couple of hundred bucks, right?).


-- chuck mcmath

+++

From: [e-mail] (Dave Seaman)

In article <[e-mail]> [e-mail] (Chuck
McMath) writes:

 [Re:  Pascals for instructional use]

> MacPascal does not exist any longer (I believe).  Symantec (publishers of
> Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
> seen it, but I believe that it's an updated MacPascal - an interpreter, not
> a compiler.  I owned MacPascal when it existed, and frequently got into
> situations where it did not suffice for my purposes.  However, I was trying
> to do all sorts of crazy Mac-like things, not take a course in programming.

MacPascal is (was?) an actual Pascal compiler/development system for the Mac
(taken over from APDA, I think).  I do not know whether there is a
System-7-compatible version.  However, this is not the same as Just Enough
Pascal, which is not a compiler/development system, but a desk accessory
(remember those?) which is intended to be used as a learning aid with an
earlier version of Think Pascal (about version 2.0, I think, though most of it
still makes sense if used with later versions).  JEP walks the user through the
process of creating a working program for the Mac, but it depends entirely on
the THINK Pascal environment for its editing, compiling and linking facilities.

--
Dave Seaman
[e-mail]

+++

From: [e-mail] (Eric W. Douglas)
Subject: Re: pascal on the mac, 1st programming course

[e-mail] (Chuck McMath) writes:

>In article <[e-mail]>, [e-mail] (Claude Lapointe) writes:
>>
>>
>> My daughter (college freshman) is taking her 1st programming
>> course, pascal.
>>
>> borland's pascal is provided by the school for both their
>> ibm lab and mac lab.
>>
>> The instructor uses a mac (as does my daughter, who will shortly
>> get her very own IIci 5/80 w cache), dislikes borland's pascal,
>> and recommends THINK pascal (states it is much more powerful
>> and complex than is needed but has documentation) and MacPascal
>> (which he uses himself, but which has no documentation).
>>
>> I need some advice in a hurry.
>>

One more thing I forgot to tell you in my private email reply: the
LightsBug debugger in THINK Pascal would be excellent for the student
trying to debug their assignments. Using THINK Pascals built-in breakpoints
in recursive list or tree building functions would greatly increase her
productivity in tracking down where problems are occuring. When I first
got THINK Pascal 2.0, I never really paid any attention to the debugger,
but now, I wouldn't be able to work without it. (BTW: the current version
is 4.0.1)

--eric

* | Eric W. Douglas             Technojock               [phone] | *
* | I'net: [e-mail]      [e-mail] | *
* | AppleLink: STUDIO.D      Compuserve: 76170,1472       AOL: EWDOUGLAS | *
____________________________________________________________________________

+++

From: [e-mail] (RD Francis)
Organization: Ohio State Computer Science

In article <[e-mail]> [e-mail] (Chuck McMath) writes:
   In article <[e-mail]>, [e-mail] (Claude Lapointe) writes:
   > The instructor uses a mac (as does my daughter, who will shortly
   > get her very own IIci 5/80 w cache), dislikes borland's pascal,
   > and recommends THINK pascal (states it is much more powerful
   > and complex than is needed but has documentation) and MacPascal
   > (which he uses himself, but which has no documentation).

   MacPascal does not exist any longer (I believe).  Symantec (publishers of
   Think Pascal) own it, and it's now called 'Just Enough Pascal.'

Just Enough Pascal may take MacPascal's place, but (last I heard)
MacPascal 3.0 was still available from Symantec, at least to
educational institutions.
--
R David Francis     [e-mail]  -or-  [e-mail]

+++

From: [e-mail] (Thomas Aaron Insel)
Organization: University of Illinois at Urbana

[e-mail] (Chuck McMath) writes:

>MacPascal does not exist any longer (I believe).  Symantec (publishers of
>Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
>seen it, but I believe that it's an updated MacPascal - an interpreter, not
>a compiler.  I owned MacPascal when it existed, and frequently got into
>situations where it did not suffice for my purposes.  However, I was trying
>to do all sorts of crazy Mac-like things, not take a course in programming.

Just Enough Pascal is NOT, I repeat NOT, MacPascal.  It is a tutorial for use
with THINK Pascal, and useless on its own.

Now that that's off my chest, THINK Pascal is quite possibly the best Pascal
for use with the Mac.  Almost any Pascal will work just fine if you're doing
elementary programming, but if you want to program for the Toolbox, THINK is
the way to go.  It's nearly as powerful, much cheaper, and much easier to use
than its main competitor, MPW.

--
Thomas Aaron Insel ([e-mail])
  s-mail: URH 227 Saunders, 906 W. College, Urbana IL 61801
  I speak for myself, and not for the State or University of Illinois.
  Cute quote and/or drawing deleted courtesy U of I.

+++

From: [e-mail] (Clarence Din)
Organization: University of Pennsylvania

In article <[e-mail]> [e-mail] (Chuck McMath) writes:
>In article <[e-mail]>, [e-mail] (Claude Lapointe) writes:
>MacPascal does not exist any longer (I believe).  Symantec (publishers of
>Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
>seen it, but I believe that it's an updated MacPascal - an interpreter, not
>a compiler.  I owned MacPascal when it existed, and frequently got into
>situations where it did not suffice for my purposes.  However, I was trying
>to do all sorts of crazy Mac-like things, not take a course in programming.

No, no, no!!!   Just Enough Pascal is NOT MacPascal.  It happens to be
a small tutorial on using and programming THINK pascal.  You get to
learn the basics of THINK pascal programming in 20 lessons with this
product.  Maybe you are thinking of something else?
>
>I am not sure of the price difference between Think Pascal and Just Enough
>Pascal, but if either you or your daughter have ANY interest in programming
>the Mac for fun or profit, spring for Think Pascal (after all of the tuition
>you're paying, what's another couple of hundred bucks, right?).

THINK Pascal 4.0 ... list $199 (or $249?)... at MacWarehouse $169
Just Enough Pascal ... MacWarehouse $55
- -------------------------------------------------------------------------
Clarence K. Din                                                   "scholar"
Programmer Analyst II, Language Analysis Center, University of Pennsylvania
"Flame me, not my employer.  My opinions are my own!"
[e-mail]

+++

From: [e-mail] (Terry Lee Thiel)
Organization: University of Illinois at Urbana

>MacPascal does not exist any longer (I believe).  Symantec (publishers of
>Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
>seen it, but I believe that it's an updated MacPascal - an interpreter, not
>a compiler.
Yikes! Just a little bit of misinformation there.  Just Enough Pascal is NOT a
compiler, it is a tutorial for learning pascal and requires Think Pascal to
operate.

+++

From: [e-mail] (Terry Lee Thiel)
Organization: University of Illinois at Urbana

>MacPascal does not exist any longer (I believe).  Symantec (publishers of
>Think Pascal own it, and it's now called 'Just Enough Pascal.'
>Just Enough Pascal may take MacPascal's place, but (last I heard)
>MacPascal 3.0 was still available from Symantec, at least to
>educational institutions.
Please!  MacPascal is dead and has been for a long time.
Just Enough pascal IS NOT A COMPILER!!!  It is a TUTORIAL!

+++

From: [e-mail] (Keith Conover)
Subject: Re: pascal on the mac, 1st programming course
Organization: People-Net [pnet01], El Cajon CA

Just Enough Pascal is neither a Pascal interpreter or compiler, its a
tutorial for Think Pascal.

Keith Conover
[e-mail]

UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!kcon
ARPA: crash!pnet01![e-mail]
INET: [e-mail]

+++

From: [e-mail] (Dennis Cohen)
Subject: Re: pascal on the mac, 1st programming course
Organization: Claris Corporation, Santa Clara CA

[e-mail] (Chuck McMath) writes:

...Message being replied to removed:

>There are really two alternatives: Think Pascal is certainly one, and for
>your daughter it _may_ be overkill.  It is an excellent product, and has
>been around a while.  You can do just about whatever you want to with it,
>and the debugging facilities are nice.

>MacPascal does not exist any longer (I believe).  Symantec (publishers of
>Think Pascal) own it, and it's now called 'Just Enough Pascal.'  I have not
>seen it, but I believe that it's an updated MacPascal - an interpreter, not
>a compiler.  I owned MacPascal when it existed, and frequently got into
>situations where it did not suffice for my purposes.  However, I was trying
>to do all sorts of crazy Mac-like things, not take a course in programming.

>I am not sure of the price difference between Think Pascal and Just Enough
>Pascal, but if either you or your daughter have ANY interest in programming
>the Mac for fun or profit, spring for Think Pascal (after all of the tuition
>you're paying, what's another couple of hundred bucks, right?).

The above information is fundamentally in error.  MacPascal is currently in
version 3.0, (revised about 1 year ago) and is available to educational
installations exclusively through Symantec's educational distributor.  Just
Enough Pascal is a desk accessory educational product which requires THINK
Pascal -- JEP is an set of tutorial sessions in which the student follows
along in THINK Pascal.

MacMillan has also just released MetroWerks Pascal for the Mac.  It is Turbo
5.5-compatible (according to the claims, which appear to early inspection to
be accurate), has a reasonable source-level debugger, and lists for $79 to
the public with an educational price somewhere around $40 and $50.  It is
essentially the same environment as MetroWerks Modula-2 and appears to be
quite stable so long as you don't have Jasik's Debugger installed.  If there
needs to be a fair amount of Turbo compatibility, your daughter and her
instructor might be well advised to check out this new product (it debuted
at MacWorld Expo last week).  The manual and tutorial material are both
good and extensive (hard-bound book with the disks attached inside the back
cover).



--
| Dennis Cohen     [e-mail]   COHEN2   AFC DCohen    71076,1377
|                  Internet       AppleLink  AmerOnline    CompuServe
| Disclaimer:  Any unattributed opinions expressed above are _MINE_!

+++

From: [e-mail] (Rich Siegel)
Organization: Symantec Language Products Group

[implicit references to previous messages in this thread, in which various
bits of misinformation are tossed about...]

- Macintosh Pascal is an interpretive Pascal programming environment, which
is ideal for educational usages, but pretty well unsuited for anything beyond
that. It was originally produced by THINK Technologies and released with the
original Macintosh in 1984. It was sold by Apple under the Apple label until
1989, when Apple turned over production and sales rights to Symantec (which
had in the meantime acquired THINK Technologies).

Mac Pascal's limitations are that it's not 32-bit clean; there are also no
guarantees as to its performance or reliability when VM is running, or under
System 7 in general, although there have been no reports of problems.

Mac Pascal is only available to educational institutions, so it may or
may not be available in a college's bookstore.

- THINK Pascal is a full-blown production development environment, which
retains enough of its Mac Pascal roots that it's reasonably easy for novices
to use (with an hour's instruction, perhaps...). It is used by many educational
institutions. It is completely 32-bit clean, VM compatible, and System 7-
compatible.

The THINK Pascal debugger is a functional superset of the Mac Pascal debugger;
it offers the same Instant and Observe windows, and in addition, it offers
LightsBug, which is a structured all-purpose structured data-view window.

- Just Enough Pascal is not a development environment. It is a tutorial
desk accessory, which, when used in conjunction with THINK Pascal version 2.0
or better, teaches the basics of Pascal programming. It is not, however,
a supplement  or replacement for Macintosh Pascal.

R.
--
- ---------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Senior Software Engineer                 Applelink: SIEGEL
Symantec Languages Group

+++

From: [e-mail] (Claude Lapointe)
Organization: Ballistic Research Lab (BRL), APG, MD.

Thanks to all who provided advice. I've received so many replies that
I can't thank everyone individually.

The overwhelming preponderance of opinion was that there simply is no
contest - THINK Pascal is the one to get for a variety of reasons,
including its documentation, support, debugger, and Pascal-templated
editor which does at least rudimentary syntax checking even before
compilation.

One or two people stated they were pleased with Borland's product,
but most said it was essentially dead, and had been so for several
years.

There were one or two mentions each of the existence of a new pascal
product by Macmillan and of a (new?) product by Symantek, Just Enough
Pascal.

One person said I should buy my daughter a NeXT rather than a IIci,
and gave some reasons.

- ----------------------

I'm going to buy THINK Pascal.

Were the machine primarily for me, I'd strongly consider a NeXT, but
it's for my daughter, at least until she graduates. She most emphatically
doesn't need to be the only (or almost only) person on campus with a
particular machine no matter how wonderful it might be, nor does she
need (as a novice) to contend with UNIX, which, although a powerful,
user-efficient, and remarkably portable OS, is also notoriously
expert-friendly.

- ----------------------

Does anyone have Symantek's phone number?

Thanks again.

------------------------------

End of C.S.M.P. Digest
******************************